Development environments are fundamentally centered on creating new object types. Often, it is desirable to expose these new types in a design time environment. Conventionally, exposing new types poses a problem because in order to use a new type, it must first be compiled. As well, situations exist when the user code cannot be compiled at a given time (e.g., it is in mid-development cycle). Even when the code can be successfully compiled, once a type is loaded into an application domain, the domain must be unloaded in order to load a new type.
Unloading a domain in the design environment is not supported in today's designer systems. Rather, types are loaded explicitly by a type resolution service and never unloaded. When new versions of types are introduced due to user changes, designers hosting instances of these types are saved to source code and reloaded. There are a number of unfortunate side-effects related to this conventional process. First, reloading a designer can be expensive. For example, live running objects must be converted to source code and re-parsed from that source code. Second, the “undo” state is lost during a reload. Additionally, because designers run in one domain, each reload leaks types defined in the user solution which, consequently, causes a slow memory leak.
As distributed object systems have become more popular, the ability to employ development tools with user interface (UI) elements has increased. For example, applications exist that include comprehensive tool sets for rapidly building and integrating web services, personal computer applications and web solutions. More particularly, development tools often include visual designers used to design user interface elements.
Traditionally, these visual designers focus only on the task at hand. However, when designing an application, a developer often needs to link the UI being designed to external objects such as data sources, images and other resources. Because the visual designer is designed to work with running instances of objects, there is no way for multiple designers to share resources from other locations within the development project. Therefore, there exists a need for a system that provides a mechanism for creating and utilizing global objects (e.g., virtual types that appear as real types) that can be used effectively by visual designers.